Interrupt handler

An interrupt handler, also known as an interrupt service routine (ISR), is a callback subroutine in microcontroller firmware, operating system or device driver whose execution is triggered by the reception of an interrupt. Interrupt handlers have a multitude of functions, which vary based on the reason the interrupt was generated and the speed at which the interrupt handler completes its task.

An interrupt handler is a low-level counterpart of event handlers. These handlers are initiated by either hardware interrupts or interrupt instructions in software, and are used for servicing hardware devices and transitions between protected modes of operation such as system calls.

Contents

Overview

In several operating systems - Linux, Unix, Mac OS X, Microsoft Windows, and some other operating systems in the past, interrupt handlers are divided into two parts: the First-Level Interrupt Handler (FLIH) and the Second-Level Interrupt Handlers (SLIH). FLIHs are also known as hard interrupt handlers or fast interrupt handlers, and SLIHs are also known as slow/soft interrupt handlers, Deferred Procedure Call.

A FLIH implements at minimum platform-specific interrupt handling similarly to interrupt routines. In response to an interrupt, there is a context switch, and the code for the interrupt is loaded and executed. The job of a FLIH is to quickly service the interrupt, or to record platform-specific critical information which is only available at the time of the interrupt, and schedule the execution of a SLIH for further long-lived interrupt handling.

FLIHs cause jitter in process execution. FLIHs also mask interrupts. Reducing the jitter is most important for real-time operating systems, since they must maintain a guarantee that execution of specific code will complete within an agreed amount of time. To reduce jitter and to reduce the potential for losing data from masked interrupts, programmers attempt to minimize the execution time of a FLIH, moving as much as possible to the SLIH. With the speed of modern computers, FLIHs may implement all device and platform-dependent handling, and use a SLIH for further platform-independent long-lived handling.

FLIHs which service hardware typically mask their associated interrupt (or keep it masked as the case may be) until they complete their execution. An (unusual) FLIH which unmasks its associated interrupt before it completes is called a reentrant interrupt handler. Reentrant interrupt handlers might cause a stack overflow from multiple preemptions by the same interrupt vector, and so they are usually avoided. In a priority interrupt system, the FLIH also (briefly) masks other interrupts of equal or lesser priority.

A SLIH completes long interrupt processing tasks similarly to a process. SLIHs either have a dedicated kernel thread for each handler, or are executed by a pool of kernel worker threads. These threads sit on a run queue in the operating system until processor time is available for them to perform processing for the interrupt. SLIHs may have a long-lived execution time, and thus are typically scheduled similarly to threads and processes.

In Linux, FLIHs are called upper half, and SLIHs are called lower half or bottom half. This is different from naming used in other Unix-like systems, where both are a part of bottom half.

Comparison Between Subroutine And ISR

  1. As discussed earlier, routine executed in response to an interrupt is called as the interrupt service routine(ISR).
  2. Subroutine is the part of a big program which perform some specific part related to the program.
  3. Subroutine is called by the program itself. It helps to avoid complexity in the program.
  4. ISR is the code executed in response to the interrupt which may occur during the execution of a program.
  5. ISR may have nothing in common to the program which is being executed at the time of interrupt is received.
  6. In the case of subroutine, only address of next field is stored in the stack automatically when it is called while in the case of ISR, along with the address of next field, content of status register and some other registers(if required) are also stored.[1]

General Sequence Followed When Interrupts Occur By an External Device

  1. Interrupt request(IRQ) signal is sent by the device to the processor.
  2. If the interrupt line is enabled the following sequence of events occur in the system, else the interrupt is ignored. The processor completes its present instruction (if any) and pay attention to the IRQ.
  3. It stores the address of the next location and content of status register to the stack
  4. It informs the device that its request has been granted and in response the device de-activates its IRQ.
  5. Using some suitable technique the processor loads its program counter(PC) with address of the ISR.
  6. With return statement occurring at the end of the ISR all stored content is loaded back into the respective registers and the processor resumes its suspended program.[1][2]

Handling Multiple interrupting Devices

There exists four ways in which processor can control multiple interrupting devices:

  1. using multiple interrupt lines;
  2. using software polling;
  3. using hardware polling (vector method);
  4. using bus arbitration.

Multiple Interrupt Lines

It is the simplest way. Here by providing separate interrupt line to each device,multiple devices are handled by the processor. Disadvantage of this method is that, this lead to the increase in the hardware structure of the processor chip. hence it becomes impractical to maintain small size of the chip and providing it access to multiple external devices.

Software Polling

Here multiple devices are connected to the processor by the common line to maintain small size. To decide which device over the common line is requesting for interrupt status of the IRQ bit in the status register of the device is checked by the processor. After detecting the IRQ signal processor processor branches to an ISR whose job is to detect(to poll) which device has send IRQ signal.Here polling action is performed on the connected device one by one until a positive result(i.e. IRQ bit=1) is obtained. After positive result corresponding device is served. Disadvantage of the scheme is that, here time is unnecessarily wasted in checking the interrupting devices i.e. this technique is time consuming.

Hardware Polling (Vector Method)

Here wastage of time is avoided since device introduces itself to the processor after receiving acknowledgment(INTA)vice signal and processor immediately start executing the corresponding ISR. Device after receiving INTA signal send a special code to the processor. this code is used to access the memory location where starting address of he corresponding ISR is stored. Thus direct address obtained from the device act as a vector that points to the starting address of the ISR. Hence scheme is termed as vectored interrupt scheme.

Bus Arbitration

This technique also uses vectored interrupt. Here before sending IRQ device must get control over the system bus. Thus here only one module can raise the IRQ signal at a time.[2]

Interrupt threads

Several operating systems - Solaris, NetBSD, Mac OS X, WinCE and FreeBSD, for example — use different scheme known as interrupt threads. An interrupt handler provided by the device driver is just a high-priority thread which runs with interrupts enabled and, more importantly, may block on mutex. This greatly simplifies locking in the kernel. In addition, an interrupt thread may be preempted by some higher-priority interrupt thread.

Symbian OS

Due to (amongst other reasons) extended processing in a ISR delays the servicing of other interrupts, Symbian OS uses Delayed Function Calls (DFCs) to perform processing that would be impossible inside the ISR [1].

See also

References

  1. ^ a b Authors:Hamacher, Zaky Book Name:Computer Organization TMH publication Fifth Edition Chapter No. 4
  2. ^ a b Authors:William Stallings Book Name:Computer Organization and Architecture PHI publication Sixth Edition Chapter No:7